DBのデータ削除、どうしてる？3つのパターンを整理

アプリケーションを開発していると、必ずと言っていいほど「データを削除する」という機能が必要になりますよね。ユーザーがアカウントを消したり、投稿を削除したり。一見、「DELETE文で消すだけでしょ？」と思いがちですが、実はデータの削除方法にはいくつかパターンがあって、それぞれにメリット・デメリットが存在します。

今回は、代表的な3つのデータ削除パターンについて、それぞれの特徴を整理してみました。

1. 論理削除 (Soft Delet)

まずは「論理削除」です。これは、データベースからレコードを物理的に消すのではなく、「このデータは削除された扱いですよ」という目印を付ける方法です。

よくある実装としては、テーブルに deleted_at (TIMESTAMP型) のようなカラムを追加しておき、通常は NULL にしておきます。データが削除されたときに、そのカラムに削除日時を記録します。

-- usersテーブルにdeleted_atカラムを追加
ALTER TABLE users ADD COLUMN deleted_at TIMESTAMP NULL;

-- ID:1 のユーザーを論理削除
UPDATE users SET deleted_at = NOW() WHERE id = 1;

-- データを取得するときは、deleted_atがNULLのものだけを対象にする
SELECT * FROM users WHERE deleted_at IS NULL;

メリット

• データの復旧が超カンタン: deleted_at を NULL に戻すだけで、すぐにデータを元に戻せます。「間違って消しちゃった！」という時に安心ですね。
• 削除したデータを分析できる: 「いつ、どのデータが削除されたか」という情報が残るので、ユーザーの行動分析などに活用できます。

デメリット

• データがDBに残り続ける: 物理的にはデータが存在し続けるので、ストレージ容量を圧迫します。
• クエリがちょっと複雑になる: データを取得する際に、必ず WHERE deleted_at IS NULL のような条件を付け忘れないように気を付ける必要があります。これを忘れると、削除したはずのデータが表示されてしまう事故につながります。

2. 物理削除 (Hard Delete)

次に「物理削除」です。これは、DELETE 文を使ってデータベースからレコードを完全に消し去る、最もシンプルな方法です。

-- ID:1 のユーザーを物理削除
DELETE FROM users WHERE id = 1;

メリット

• 実装がシンプル: DELETE 文を実行するだけなので、コードが直感的で分かりやすいです。
• ストレージに優しい: 不要なデータをDBに残さないので、ストレージの肥大化を防げます。

デメリット

• データの復旧が難しい: 一度消してしまうと、バックアップから復元しない限り元に戻せません。操作ミスが大きな障害につながる可能性があります。
• 削除の履歴が残らない: 「誰が」「いつ」データを消したのか、という情報が失われてしまいます。監査ログなどが別途必要になるケースもあります。

3. 物理削除 + 削除データ作成

最後は、上記2つの「いいとこ取り」を狙ったようなパターンです。「物理削除 + 削除データ作成」は、データを削除する際に、その内容を別のテーブル（アーカイブテーブルや削除ログテーブルなど）に保存してから、元のテーブルからは物理削除する方法です。

-- 1. 削除対象のデータをdeleted_usersテーブルにコピー
INSERT INTO deleted_users (id, name, email, created_at, deleted_at)
SELECT id, name, email, created_at, NOW() FROM users WHERE id = 1;

-- 2. 元のテーブルからは物理削除
DELETE FROM users WHERE id = 1;

メリット

• 本番テーブルのパフォーマンス維持: 論理削除と違って、普段使うテーブルには不要なデータが残らないため、パフォーマンスの低下を防げます。
• 削除履歴の保持: 削除したデータそのものや、削除した日時を別のテーブルでしっかり管理できます。コンプライアンス要件などで削除ログが必要な場合に有効です。

デメリット

• 実装が複雑になる: データをコピーして、その後に削除するという2段階の処理が必要になるため、実装の手間が増えます。トランザクション管理などをしっかり行う必要があります。
• アーカイブテーブルの管理: 削除データを保存しておくテーブルも、データが増え続ければいずれメンテナンスが必要になります。

まとめ

どの削除パターンを選ぶべきかは、そのデータが持つ意味や、システムの要件によって決まります。

データ削除は、設計段階でどのパターンを採用するかをしっかり検討しておくことが大切です。それぞれの特徴を理解して、自分のシステムに最適な方法を選んでみてください。